Hey @jackforesightmobile , thanks for this. I have similar feedback on this one and the one in the kotlin client.

I appreciate that we want to keep things consistent between these clients and the other SDKs, but I think this adds extra confusion at this point since getFeatureFlags and getIdentityFlags are doing very similar things (as far as I can tell).

As far as I can see, we have a few options here that might be better:

1. Add an optional traits argument to the existing getFeatureFlags method (and raise an exception if they are provided without an identity).
2. (Breaking change) Update the method signature to the getFeatureFlags method that takes a new Identity object which includes the identifier and (optionally) any traits.
3. (Breaking change) Remove the identity argument from the getFeatureFlags method in favour of getIdentityFlags.

I think my preference at this point is (1), but I'm keen to know what you think from an idiomatic swift / kotlin perspective?

Hi @matthewelwell, I think I would agree that option 1 would be the best. I can implement that no problem and I'll update the docs to reflect the change to the method.